your change to the release script could conflict with #5369.

It should not conflict, those are new workflows. But we would also want to translate those, I imagine.

Yes, this was meant. Could you do this and we drop my PR?

Done, I think :)

very much in favor of Nix in CI, that should be long-term reproducible than Docker (claim that I would love to substantiate with a link to a thesis or paper).

@monperrus could you disable the beta release workflow in the spoon-deploy repo, see https://docs.github.com/en/actions/using-workflows/disabling-and-enabling-a-workflow?

So in the future, we write bash scripts for advanced stuff and call them from nix?

There are many ways to do things. I currently added small commands as dev commands (writeShellBin in the flake.nix) and larger ones got their own bash script in chore (following established precedent there). The idea is that we use a coherent language that works everywhere and does not depend on github (actions) wherever possible. This allows people to run things locally and the more inputs we can track in Nix, the easier it is to reproduce behaviour locally. We could also use python or something else, if you prefer that. bash is just quick'n'dirty to write, but I am a Linux user :P Maybe you have a nice windows idea, though the Nix env only works on Linux and Mac.

I also see the irony with #5333, but we got caching for free and eliminated random setup commands.
We could also split up the script in a few separate scripts that run in parallel jobs:

1. Add a job that builds spoon and stashes the resulting maven repository in a new job-local cache
2. Use a matrix job that depends on the first job to spawn the factored scripts in parallel

@monperrus could you disable the beta release workflow in the spoon-deploy repo, see https://docs.github.com/en/actions/using-workflows/disabling-and-enabling-a-workflow?

done

Thanks @I-Al-Istannen. Let's do the first test at 0 UTC and watch the snapshot release?

super cool thanks @I-Al-Istannen

let's document this a bit? could you edit #5415 accordingly?

• I needed to package two libraries (semver and jreleaser) myself as they are not in nixpkgs. Jreleaser's build process has ample opportunities for improvement: It fails tests, or jdk downloads, or something else everytime I run it — ON ITS RELEASE commit. So now we package the jreleaser binary instead.
  Packaging things ourselves means we are responsible for updates though

Nix support is in the roadmap, both for JReleaser itself and every other consumer. jreleaser/jreleaser#1032

@aalmiray

I think I will have a look at nicer nix maven builds in the upcoming future too (it ties in quite nicely with https://github.com/chains-project/maven-lockfile and gradle supports dependency lockfiles for years now). As far as I can tell, packaging things for maven currently is a bit annoying and needs to rely on fixed-output derivations, which will need updates for very minor dependency update. But my Nix game is not strong at all :P

For the moment the binary packaging I built in this PR seems to work just fine (it is basically a minimal nix version of your java download script from the jreleaser-action). Source-based packaging is a bit annoying in CI, unless you can offload the binary cache to hydra :P We build z3 from source, but it is cached in GitHub actions — still takes ~30 minutes for the initial CI run though, until the package is in the GitHub cache.

I was a bit surprised that I did not manage to even build Jreleaser manually (I first tried to have a from-source derivation). I have no idea how you do it, but everything I tried to build it failed, even on the release commit. It's probably me being stupid, but maybe something on your side is a tad weird too?

I was a bit surprised that I did not manage to even build Jreleaser manually (I first tried to have a from-source derivation). I have no idea how you do it, but everything I tried to build it failed, even on the release commit. It's probably me being stupid, but maybe something on your side is a tad weird too?

Given that JReleaser is a Java project built with a very specific version of Gradle I'd suspect it may not be possible to build it from a Nix environment without network access.

It should be enough to run gradlew build with Java 11 or greater to build the project. Note that the given Gradle wrapper must be used, no other wrapper or command will do.

Given that JReleaser is a Java project built with a very specific version of Gradle I'd suspect it may not be possible to build it from a Nix environment without network access.

You can access the internet if you know the hash of the result (which only helps if you have useful lockfiles). Nix packages gradle 6.9.4, maybe that would work as well. But I am happy with just taking your binary at face value right now :)

It should be enough to run gradlew build with Java 11 or greater to build the project. Note that the given Gradle wrapper must be used, no other wrapper or command will do.

I tried it on my host as well, but didn't notice that my system locale was screwing things over there… Classic :P I made a tiny PR with a potential fix.

Thank you for the help and enjoy your evening :)

Thank you for the PR, I;ll have a look at it shortly.

FWIW JReleaser's binaries come with SBOMs, SHAs, digitial signatures, and SLSA provenance. Thus, allowing multiple ways to verify them.

Given the test list:

• Snapshot Releases
• Beta Releases
• Real Maven Central release

Two are left. Do you want to wait for a beta release, or shall we try patch release first?

Okay we did patch release test and it works. First spoon release with the new nix CI 🎉 https://github.com/INRIA/spoon/tree/v10.4.1